<html>
<head><meta charset="utf-8"><title>Lint policy · t-lang · Zulip Chat Archive</title></head>
<h2>Stream: <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/index.html">t-lang</a></h2>
<h3>Topic: <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Lint.20policy.html">Lint policy</a></h3>

<hr>

<base href="https://rust-lang.zulipchat.com">

<head><link href="https://rust-lang.github.io/zulip_archive/style.css" rel="stylesheet"></head>

<a name="228753991"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Lint%20policy/near/228753991" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Lint.20policy.html#228753991">(Mar 04 2021 at 11:16)</a>:</h4>
<p>I'd like to continue discussion of the lint policy here, continuing from the <a class="stream" data-stream-id="268952" href="/#narrow/stream/268952-edition-2021">#edition 2021</a> topic <a href="#narrow/stream/268952-edition-2021/topic/lint.20promotions">here</a>. We're getting close to solidifying the plans for Rust 2021, and I think it's worth discussing the lint policy here divorced from Rust 2021 particulars. <span class="user-mention" data-user-id="116009">@nikomatsakis</span> has created <a href="https://hackmd.io/i1Ob4XS6TwuUv-rOVEoM4A">a document</a> outlining a proposed policy on linting and how this relates to semver and editions. The policy is reaching a point where we can potentially discuss it formally in a lang team meeting, but there are still some open questions we should get through.</p>



<a name="228754428"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Lint%20policy/near/228754428" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Lint.20policy.html#228754428">(Mar 04 2021 at 11:20)</a>:</h4>
<p>One interesting one was brought up <a href="https://github.com/rust-lang/rust/issues/80165#issuecomment-789749153">here</a>. While in an ideal world, future incompatibility warnings for bugs can be made into hard errors across all editions without technically breaking backwards compatibility promises, there are some bugs that would break so much of the eco system that we may not wish to actually go through with such a policy. It might then make more sense for the lint to be turned into an error on an edition boundary so that future code does not accidentally continue to write such "buggy code" and so that code bases can opt into the breakage more smoothly.</p>



<a name="228754692"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Lint%20policy/near/228754692" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Lint.20policy.html#228754692">(Mar 04 2021 at 11:22)</a>:</h4>
<p>On a somewhat related note, I think we've often talked about future compatibility warnings as bug fixes, but I don't think everyone thinks of them strictly as such. For instance, <a href="https://github.com/rust-lang/rust/issues/82730">https://github.com/rust-lang/rust/issues/82730</a> wants to move what is now a warning to a hard error in a future edition, and proposes to use a future compatibility warning to transition users. We should make sure that policies around transitioning warnings to errors in non-bug-fix cases, touches on the use of future compatibility warnings.</p>



<a name="228825372"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Lint%20policy/near/228825372" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Lint.20policy.html#228825372">(Mar 04 2021 at 18:29)</a>:</h4>
<p><span class="user-mention silent" data-user-id="224872">rylev</span> <a href="#narrow/stream/213817-t-lang/topic/Lint.20policy/near/228754428">said</a>:</p>
<blockquote>
<p>One interesting one was brought up <a href="https://github.com/rust-lang/rust/issues/80165#issuecomment-789749153">here</a>. While in an ideal world, future incompatibility warnings for bugs can be made into hard errors across all editions without technically breaking backwards compatibility promises, there are some bugs that would break so much of the eco system that we may not wish to actually go through with such a policy. It might then make more sense for the lint to be turned into an error on an edition boundary so that future code does not accidentally continue to write such "buggy code" and so that code bases can opt into the breakage more smoothly.</p>
</blockquote>
<p>I personally think it should be <em>incredibly rare</em> that we end up breaking something in an older edition, or forcing a transition in an older edition. The only case where I'd really want to do that is a serious soundness issue.</p>



<a name="228825578"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Lint%20policy/near/228825578" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Lint.20policy.html#228825578">(Mar 04 2021 at 18:30)</a>:</h4>
<p>I certainly wouldn't want to do it for something like <code>dyn Trait</code> (even though there's parsing value in removing it), or anything else where the old way is still <em>functional</em> and <em>correct</em>.</p>



<hr><p>Last updated: Aug 07 2021 at 22:04 UTC</p>
</html>